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A PACKET-BASED TELEMEDICINE SYSTEM FOR 
COMMUNICATING INFORMATION BETWEEN 

CENTRAL MONITORING STATIONS AND 
REMOTE PATIENT MONITORING STATIONS 

CROSS REFERENCE TO RELATED APPLICATION 

This application claims priority to and the benefit of the filing date of 
copending provisional application entitled AN ELECTRONIC HOUSE CALL 
SYSTEM, assigned Serial No. 60/026,986, filed September 20, 1 996 (Attorney 
Docket Number 62002-8450), which is hereby incorporated herein by reference. 

TECHNICAL FIELD OF T HE INVENTION 

This invention generally relates to the field of telemedicine and, more 
particularly, to a telemedicine system which communicates information between 
central monitoring stations and remotely-located patient monitoring stations by 
encapsulating the data in packets which can be sent over multiple types or 
combinations of network architectures. 

BACKGROUND OF THE INVENTION 

Generally, telemedicine is a term used to describe a type of patient care 
which involves monitoring of a patient's condition by a healthcare worker located at 
a healthcare facility which is remote with respect to the location of the patient. 
Telemedicine, if adequately employed, is capable of providing enormous benefits to 
society. One such benefit is that patients can be examined without having to travel 
to a healthcare facility. This feature is particularly important for patients who live 
in remote areas who may not be able to easily travel to the nearest healthcare 
facility, or who need to be examined by a healthcare worker located far away from 
the patient, in another state, for example. 

Another benefit of telemedicine is that it is capable of allowing a patient to 
be examined more often than would be possible if the patient were required to travel 
to a healthcare facility due to the ease with which it can be administered. For 
example, if a patient's condition requires that measurements be taken several times 
a day, it would be impractical for the patient to travel to and from a healthcare 
facility each time a measurement needs to be taken. It probably would be necessary 
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for the patient to be admitted to the healthcare facility. The use of telemedicine 
could allow these measurements to be taken at the patient's home while the 
healthcare worker observed the patient or the measurement data from the healthcare 
facility. 

Another benefit of telemedicine is that it allows a patient to be examined in a 
more timely manner than if the patient was required to travel to the healthcare 
facility. This is important in urgent situations, such as when a patient's condition 
becomes critical and emergency procedures must be taken immediately. 

Many various types of telemedicine systems are known. One example of 
such a system is disclosed in David et al. , U.S. Patent No. 5,441,047, issued August 
15, 1995, which discloses an ambulatory patient health monitoring system for 
monitoring a remotely-located healthcare patient from a central station. The system 
includes instruments at the remote location for measuring the medical condition of the 
patient. The medical condition may correspond to health parameters, such as heart 
rate, respiratory rate, pulse oximetry and blood pressure. The system includes a first 
audio-visual camera disposed at the patient location and a second audio-visual camera 
disposed at the central station. Audio and video information is transmitted between 
the patient's remote location and the central station via a communications network, 
such as an interactive cable television network. Patient (lata is transmitted between 
the patient remote location and the central station by a separate communications 
network, such as satellite, radio transmission or telephone lines. A display is located 
at the patient's remote location and at the central station to allow the patient and the 
healthcare worker to observe each other simultaneously. 

One of the disadvantages of the system disclosed in the David et al. patent is 
25 that, although it refers to sending the information between the healthcare worker and 
the patient via various types of networks, the information sent from the patient's home 
will have to be formatted in accordance with a different communications protocol for 
each of these different networks. Therefore, although the David et al. patent refers to 
the capability of using different types of networks, the system disclosed in the David 
30 et al. patent is not "network-independent" because the data must be formatted in 
accordance with a particular protocol at the sending end and the formatting process 
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will have to be reversed at the receiving end in a different manner for each type of 
network. At the very least, this will require different software and/or hardware at 
each end for each different transmission media used. Another disadvantage of the 
system disclosed in the David et aL patent is that the audio and video data are sent 
over one communications network and the patient data is sent over another 
communications network. 

Another example of a telemedicine system is disclosed in Tamura, U.S. Patent 
No. 5,434,611, issued July 18, 1995. This patent discloses a telemedicine system 
having a two-way CATV network for transmitting images, voice and data between 
equipment located at the patient's home and equipment located at a medical office. 
Cameras are located in both the patient's home and in the medical office to provide 
return images between the doctor and the patient. In order for the doctor's terminal to 
communicate with the patient's terminal, the doctor's terminal sends a signal over a 
control line to the patient's terminal. A line controller then selects a communication 
channel for the session by selecting an unused channel in a multiple channel access 
(MCA) system. The terminals then automatically tune to the assigned 
communications channel and the information is communicated over the assigned 
channel between the patient and the doctor. 

One disadvantage of the system disclosed in the Tamura patent is that any 
communication between the doctor and patient must be set up by sending a signal 
which the line controller detects. The line controller then selects an unused channel 
for the communication. It also appears that the signal must be initiated by the doctor 
because the text of the patent only describes the situation where the doctor sends the 
signal to initiate the session. In any event, the system requires that a direct 
connection be made between the patient's terminal and the doctor's terminal. No 
provision is made for allowing medical measurement data to be sent to the doctor's 
terminal without a direct connection being made between the patient's terminal and 
the doctor's terminal. Therefore, in accordance with the system disclosed in the 
Tamura patent, it would be impossible for information relating to the patient's 
condition to be sent by the patient's terminal to the doctor's terminal in the absence of 
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a direct connection being made between the terminals, which requires that the doctor 
be present for the session. 

It would be advantageous to provide a telemedicine system which would allow 
either a patient or a healthcare worker to initiate a diagnostic session to cause 
5 diagnostic measurements to be taken and sent to a location, such as a healthcare 
facility, where medical files could be automatically updated by the data. One 
advantage of such a system is that a healthcare worker would not have to administer a 
diagnostic session and, therefore, would not have to participate in the session. 
Another advantage of such a system is that medical files could be automatically 

10 updated without any action on the part of a healthcare worker being required. 

Furthermore, as the medical files are automatically updated, the patient's condition 
could be automatically monitored so that, in the event that the patient's condition falls 
below a predetermined level, remedial measures can be taken. It would also be 
advantageous to provide a telemedicine system which would allow video, voice and 

15 medical data to be integrated and sent over a single network. 

Accordingly, a need exists for a telemedicine system which is network- 
independent and which is capable of allowing video, voice and data relating to the 
patient's condition to be integrated and sent from a remotely-located patient terminal 
to a healthcare facility without the necessity of a direct connection being set up 

20 between the patient and the healthcare worker. 

SUMMARY OF THE INVENTION 

The present invention provides a packet-based telemedicine system for 
communicating video, voice and medical data between a central monitoring station 

25 and a patient monitoring station which is remotely-located with respect to the 
central monitoring station. The patient monitoring station obtains digital video, 
voice and medical measurement data from a patient and encapsulates the data in 
packets and sends the packets over a network to the central monitoring station. 
Since the information is encapsulated in packets, the information can be sent over 

30 multiple types or combinations of network architectures, including a Community 
Access Television (CATV) network, the Public Switched Telephone Network 
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(PSTN), the Integrated Services Digital Network (ISDN), the Internet, a local area 
network (LAN), a wide are network (WAN), over a wireless communications 
network, or over an asynchronous transfer mode (ATM) network. Thus, a separate 
transmission protocol is not required for each different type of transmission media. 
5 Rather, a single transport layer protocol is used for encapsulating the information in 
packets at the sending end and for de-encapsulating the information at the receiving 
end. Furthermore, by sending the information in packets, the video, voice and 
measurement data can be integrated and sent over a single network. 

When the information has been de-encapsulated at the central monitoring 

10 station, the information is processed and analyzed by software and/or hardware to 
determine which patient caused the information to be sent, the type of diagnostic 
measurement comprised in the information, and the diagnostic measurement 
represented by the information. 

The patient monitoring station of the telemedicine system of the present 

15 invention comprises a plurality of medical devices which are connected to a control 
unit via a medical device interface which controls the transmission of data from the 
medical devices to the control unit. The patient monitoring station is configured so 
that the control unit and the medical devices can communicate with each other 
through the medical device interface. The medical device interface preferably uses 

20 a single interrupt to request data transfer to the control unit. When the control unit 
has data to send to one of the medical instruments, it transmits the data to the 
medical device interface along with the address of the medical device that is to 
receive the data. The medical device interface then decodes the address and 
transmits the data to the proper medical device. 

25 When a medical device has data to send to the control unit, it transmits the 

data to the medical device interface. The medical device interface then sends an 
interrupt request to the control unit. The control unit processes the interrupt request 
and the data is transmitted from the medical device interface to the control unit. 
The control unit then formats the data and outputs it to a communications device, 

30 preferably a LAN card, which encapsulates the data in accordance with the 
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transport layer protocol and outputs it onto the network to be sent to the central 
monitoring station. 

The control unit of the patient monitoring station also comprises a 
videoconferencing interface device which formats voice and video data received by 
the videoconferencing interface device from a camera and microphone located at the 
patient monitoring station. The control unit then delivers the formatted video and 
voice data to the communications device which encapsulates the data in accordance 
with the communications protocol and outputs it onto the network to be sent to the 
central monitoring station. 

The central monitoring station also comprises a control unit which 
preferably is identical to the control unit of the patient monitoring station. The 
control unit of the central monitoring station communicates with a 
videoconferencing interface device of the central monitoring station which formats 
voice and video data received by the videoconferencing interface device from a 
camera and microphone located at the central monitoring station. The control unit 
then delivers the formatted video and voice data to a communications device, 
preferably a LAN card, which encapsulates the video and voice data in accordance 
with the transport layer protocol and outputs it onto the network to be sent to the 
patient monitoring station. 

When the control unit of the patient monitoring station receives packets of 
data sent to it from the central monitoring station, the communications device of the 
patient monitoring station de-encapsulates the packets of information and determines 
whether the information is to be sent via the medical device interface to one of the 
medical devices or whether the information is to be sent to a display screen and 
speaker via the videoconferencing interface device. Once this determination is 
made, the information is sent to the appropriate interface device. 

When the control unit of the central monitoring station receives packets of 
data sent to it from the patient monitoring station, the communications device of the 
central monitoring station de-encapsulates the packets of information and determines 
whether the information is diagnostic data from one of the medical devices or 
whether the information is videoconferencing information. If the information is 
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videoconferencing information, the information is sent to the videoconferencing 
interface device. The videoconferencing interface device decodes the information 
and outputs it to a display screen and speaker located at the central monitoring 
station. If the information is diagnostic data, the control unit interprets the data. 
5 Once the diagnostic data has been interpreted, the control unit may further process 
the data and/or save it in a storage device. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram of the telemedicine system of the present invention 
10 comprising a plurality of patient monitoring stations and a plurality of central 
monitoring stations. 

Fig. 2 is a block diagram of one of the patient monitoring stations shown in 
Fig. 1 comprising N medical devices connected via a device interface to a control 
unit. 

15 Fig. 3 is a flow chart demonstrating the processing of data received by the 

control unit shown in Fig. 2 from one of the central monitoring stations shown in 
Fig. 1. 

Fig. 4 is a flow chart demonstrating the transmission of data from one of the 
medical devices shown in Fig. 2 to the control unit shown in Fig. 2 and then to the 
20 central monitoring station shown in Fig. 1. 

Fig. 5 is a flow chart demonstrating the processing and packeting of video 
and audio data at the patient monitoring station control unit shown in Fig. 2 before 
the packets are sent to the central monitoring station shown in Fig. I. 

25 DETAILED DESCRIPTION OF THE PREFE RRED EMBODIMENT 

Fig. 1 illustrates the telemedicine system 10 of the present invention 
comprising a plurality of central monitoring stations 11 which are in communication 
via a network 16 with a plurality of patient monitoring stations 18. As illustrated, a 
central monitoring station 11 may be provided at, for example, the doctor's home 
30 12, the doctor's office 13, or at a hospital 14, each of which are in communication 
with network 16. In accordance with the present invention, data of various types is 
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sent to and from one or more of the central monitoring stations 11 to and from one 
or more of the patient monitoring stations 18 in the form of digital packets, as 
discussed in more detail below with respect to Figs. 2-5. It should be noted that the 
patient monitoring stations 18 and the central monitoring stations 11 may be located 
at any location capable of having access to communication network 16. It should 
also be noted that a plurality of patient monitoring stations 18 can communicate 
with a single central monitoring station 11 and that a plurality of central monitoring 
stations 11 can communicate with a single patient monitoring station 18. 

Network 16 can be multiple types or combinations of network architectures, 
including the PSTN, ISDN, a cellular or wireless network, a LAN, a WAN, a 
Community Access Television network (CATV), the Internet, an ATM network, or 
a combination of one or more of these networks. All of the information transmitted 
between a patient monitoring station 18 and a central monitoring station 11 is 
encapsulated in packets using a preselected communications protocol. In 
accordance with the preferred embodiment of the present invention, TCP/IP is used 
as the transport layer/network layer protocol for encapsulating the data in packets. 
However, it will be apparent to those skilled in the art that other types of 
communications protocols are suitable for use with the present invention. TCP/IP 
is preferred due to its wide acceptance and use. 

Fig. 2 is a block diagram demonstrating one of the patient monitoring 
stations 18 shown in Fig. 1. Each patient monitoring station 18 comprises a control 
unit 22, an address/data bus 27, a videoconferencing interface device 26, 
videoconferencing equipment 23, a medical device interface 24, and one or more 
medical devices 28-30. In accordance with the preferred embodiment of the present 
invention, medical device interface 24 comprises a serial card that has multiple 
serial ports and uses only one interrupt line (not shown) to communicate with 
control unit 22. The medical device interface 24 is connected to a plurality of 
medical devices 28-30 and to the control unit 22 via address/data bus 27. The 
control unit 22 comprises telemedicine application software 25 which controls the 
flow of data to and from the medical devices 28-30 via the medical device interface 
24. 
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Videoconferencing interface device 26 comprises hardware and/or software 
which controls the processing of data received by the control unit 22 from the 
videoconferencing equipment 23 to convert the data into a form which is suitable 
for transmission over network 16, The videoconferencing interface device 26 is 
5 also responsible for processing videoconferencing data received from the central 
monitoring station to convert the data into a form which is suitable for display on a 
display screen comprised by videoconferencing equipment 23. 

When data is to be sent from the control unit 22 to one of the medical 
devices 28-30, the control unit 22 sends data to medical device interface 24 via 

10 address/data bus 27. Medical device interface 24 then transmits the data to the 
appropriate medical device 28-30 by decoding the address information placed on the 
address/data bus 27. When data is to be sent to control unit 22 from one of the 
medical devices, the medical device transmits the data to medical device interface 
24. Medical device interface 24 then buffers and queues the requests and then uses 

15 a single interrupt line to indicate that it has data to transmit to control unit 22. 
Once control unit 22 is prepared to receive the data, medical device interface 24 
sends the data to control unit 22 via the address/data bus 27. 

The medical devices 28-30 can include, but are not limited to, blood 
pressure devices, thermometers, pulse oximetry devices, electrocardiograms 

20 (EKGs), scales and stethoscopes. Additionally, medical devices can be freely 
interchanged with one another simply by unplugging one medical device from the 
interface and plugging in another. This "plug and play" compatibility, is made 
possible by the system configuration and use of a single interrupt interface and 
provides maximum flexibility in configuring the telemedicine system to meet 

25 particular needs. Numerous combinations of different medical devices can be used 
in one telemedicine system via the device interface. The device interface itself can 
be implemented in numerous ways, including but not limited to, an RS-232 
interface, a single serial communications card, a bus such as the Firewire (IEEE 
1394) or Universal Serial Bus (USB), or any other interface which uses a single 

30 interrupt in the data transfer process. The control unit can also be implemented in 
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numerous ways including, but not limited to, a personal computer or any other type 
of processing unit. 

Figs. 3 and 4 generally portray the steps involved in a transfer of data 
between a medical device and control unit 22. With respect to Fig. 3, when the 
5 patient monitoring station 18 receives data from the central monitoring station 11, 
control unit 22 determines whether the data is directed to one of the medical devices 
28-30, to the videoconferencing equipment 23, or to application-level data, as 
indicated by block 34. The received information is encapsulated in packets of 
digital data. The communications device (not shown) of the control unit 22 de- 

10 encapsulates the packets and the data is analyzed to determine whether the data is 
videoconferencing data, medical instrument command data, or application-level 
data, as indicated by block 35 and 36, respectively. If the data is directed to the 
videoconferencing equipment 23, the data is processed by the videoconferencing 
interface device 26 and output to videoconferencing equipment 23, as indicated by 

15 blocks 41 and 42, respectively. This data can be control commands and data for 
controlling the operation of the videoconferencing equipment 23 (e.g., controlling 
the pan or tilt of the camera), or it can be image and voice data captured by the 
videoconferencing apparatus located at the central monitoring station 11, as 
discussed in more detail below. 

20 If it is determined at block 36 that the data is application-level data, the data 

is processed within the control unit 22 by the telemedicine application, as indicated 
by block 37. Application-level data may be, for example, a message to the patient, 
status information, etc. 

If it is determined at block 36 that the received data is medical device 

25 command data, the medical device interface 24 decodes the address and enables the 
selected serial port corresponding to the requested medical device, as indicated by 
block 38. The selected serial port receives the data from the address/data bus 27, as 
indicated by block 39. The intended medical device then receives the data from 
medical device interface 24 over the selected serial port (not shown). 

30 Fig. 4 is a block diagram illustrating the transfer of data from one of the 

medical devices 28-30 to the control unit 22. In accordance with the preferred 
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embodiment of the present invention, medical device interface 24 comprises a serial 
interface card with one serial port connected to each medical device 28-30. As 
before, the telemedicine application software 25 is running on control unit 22 
during the transmission process. In step 43, one or more of the medical devices 28- 
30 sends data to medical device interface 24. The medical device interface 24 
buffers and queues the data and then invokes an interrupt using the single interrupt 
line (not shown), as indicated by block 44. The control unit 22 then invokes an 
interrupt service routine to handle the interrupt request, as indicated by block 45. 
As stated above, numerous routines for processing the resulting data can be 
included in the telemedicine application software 25 for acquiring data from the 
various types of medical devices and for converting the data into a form suitable for 
transmission to the central monitoring station 11. It will be understood by those 
skilled in the art which types of routines will be needed and the manner in which 
those routines should be constructed to accomplish these tasks. 

Once the interrupt service routine has been invoked, it processes the 
interrupt and notifies the telemedicine application software 25 of the availability of 
the data, as indicated by blocks 46 and 47. The telemedicine application software 
25 then reads the data sent by the medical device, as indicated by block 48. The 
medical device data is then sent by the control unit 22 to the communications 
device, which preferably is a LAN card (not shown), which encapsulates the data in 
packets, as indicated by block 51. The packets are then output by the LAN card 
onto the network 16, as indicated by block 52. 

The medical device interface 24 can include numerous serial ports to handle 
data sent by multiple medical devices 28-30. In essence, medical device interface 
24 itself handles all data transfer, buffering, and priority functions associated with 
using a single interrupt. Therefore, since numerous combinations of medical 
devices 28-30 can be connected to device interface 24, device interface 24 in 
conjunction with the telemedicine application software 25 provides a "plug-and- 
play n type of compatibility between the control unit 22 and the medical devices 28- 
30. Therefore, medical devices 28-30 can be connected and disconnected from 
device interface 24 in any combination. This feature of the single interrupt 
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interface 24 and telemedicine application software 25 provides maximum flexibility 
in configuring the telemedicine system 10. 

Additionally, the telemedicine application software 25 in conjunction with 
the interface 24 may perform any necessary conversion functions. The telemedicine 
application software 25 can include routines for converting data into a form 
comprehensible by one or more medical devices 28-30, by the control unit 22, or by 
medical device interface 24. This interpretation function facilitates communication 
among different devices and allows the effective use of the single interrupt device 
interface 24. However, it should be noted that although the single interrupt 
architecture of the present invention is preferred, it will be apparent to those skilled 
in the art that this is not necessary and that any means by which one or more 
medical devices 28-30 can transfer data to and from the medical devices 28-30 to 
and from the control unit 22 is suitable for use with the present invention. 

The telemedicine application software 25 in conjunction with medical device 
interface 24 may also perform the function of allowing medical devices using 
different protocols to communicate. For example, the protocol used by a medical 
device 28-30 may be different from any other medical device. The telemedicine 
application software 25 can contain routines for allowing these different protocols to 
communicate via the common device interface 24. 

Fig. 5 is a flow chart functionally illustrating the processing of 
videoconferencing data received by control unit 22 from videoconferencing 
equipment 23 via videoconferencing interface device 26. Videoconferencing 
equipment 23 includes a camera and microphone for obtaining video and audio 
images of the patient. The videoconferencing software comprised by the 
videoconferencing interface device 26 processes the video and audio input into a 
format suitable for the communications device to packet, as indicated by block 54. 
The data is then provided to the communications device, as indicated by block 55. 

As stated above, preferably the communications protocol used with the 
present invention is TCP/IP. It will be understood by those skilled in the art the 
manner in which the data is formatted prior to being sent to the communications 
device to be packeted. Generally, the data is provided to the communications 
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device in a serial bit stream. The identity of the patient and the identity of the 
central monitoring station to which the data is to be sent is also provided to the 
communications device. In the case where diagnostic measurement data from one 
or more of the medical devices is being sent with the videoconferencing data, an 
indication of the type of measurement being sent and a representation of the 
measurement itself is also provided to the communications device. Optionally, 
other types of information may also be provided to the communications device, such 
as the date and time of the measurement, the type of medical device which took the 
measurement, and the location or identity of the patient monitoring station. 

TCP/IP then parses the data into packets, each packet including a field 
indicating the destination to which the packet is being sent. The packets are then 
output by the communications device onto the network, as indicated by block 56. 
Therefore, at a nunimum, the packets sent which correspond to a particular 
• measurement will include an indication of the identity of the patient, the type of 
measurement being transmitted, and a representation of the measurement itself. The 
plurality of packet data fields define the identity of the patient, an indication of the 
type of measurement, and a representation of the measurement itself. 

The central monitoring stations 11 are essentially the same as the patient 
monitoring station, with the exception that the central monitoring stations do not 
comprise a medical device interface or the medical devices. The processing of data 
at the central monitoring stations 11 is essentially the same as that depicted in Figs. 
3 and 5 for the patient monitoring stations 18, with the exception that no data for 
controlling medical devices is received by the central monitoring stations 11. Also, 
the telemedicine software at the central monitoring stations 11 is different from the 
telemedicine software at the patient monitoring station. The telemedicine software 
at the central monitoring station includes one or more routines for analyzing 
measurement data to determine the type of measurement data received, e.g., 
whether the data is blood pressure data, temperature data, pulse oximetry data, etc. 
The telemedicine software at the central monitoring station also includes a 
functionality for determining the identity of the patient to whom the data 
corresponds. This can be accomplished by parsing the de-encapsulated data using 
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the order of the data in the de-encapsulated data stream and preselected indications 
contained in the data stream to determine the measurement type, the measurement 
itself, and the identity of the patient. 

A medical file maintained for the patient at the central monitoring station 

5 may then be updated to reflect the received measurement. Alternatively, the 
medical files may be maintained at a server located outside of the central monitoring 
stations 1 1 which is capable of being accessed by the central monitoring stations 
and/or by the patient monitoring stations 18. It will be apparent to those skilled in 
the art the manner in which such an analysis is performed. 

10 ft will be apparent to those skilled in the art that many variations and 

modifications can be made to the present invention without departing from the spirit 
and scope of the present invention. All such variations and modifications are 
intended to be within the scope of the present invention, as set forth in the following 
claims. 
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What is claimed is: 

1. A telemedicine system for transmitting voice, video and medical data 
between a central monitoring station and a patient monitoring station over a 
network, the telemedicine system comprising: 

a first control unit located at the patient monitoring station, the control unit 
receiving medical data from one or more medical instruments in communication 
with the control unit and delivering the medical data to a first communication device 
in communication with the control unit, the communication device encapsulating the 
medical data in packets in accordance with a preselected communication protocol 
and outputting the packets onto the network; and 

a second control unit located at the central monitoring station, the second 
control unit being in communication with a second communication device, the 
second communication device receiving the packets output by the first 
communication device onto the network, the second communication device de- 
encapsulating the packets to reconstruct the medical data, the reconstructed medical 
data being provided to the second control unit. 

2. The telemedicine system of claim 1, wherein the telemedicine system 
is for transmitting voice, video and medical data between a plurality of central 
monitoring stations and a plurality of patient monitoring stations, each patient 
monitoring station comprising said first control unit and each of said central 
monitoring stations comprising said second control unit. 

3. The telemedicine system of claim 1, wherein the network is a 
community access television (CATV) network. 

4. The telemedicine system of claim 1, wherein the network is an 
asynchronous transfer mode (ATM) network. 
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5. The telemedicine system of claim 1, wherein the network is the 
Internet. 



6. The telemedicine system of claim 1, wherein the network is a Public 
Swiched Telephone Network (PSTN). 

7. The telemedicine system of claim 1, wherein the network is an 
Integrated Services Digital Network (ISDN), 

8. The telemedicine system of claim 1 ( wherein the network is a local 
area network (LAN). 



9. The telemedicine system of claim 1, wherein the network is a wide 
area network (WAN). 

10. The telemedicine system of claim 1, wherein the network is a hybrid 
network consisting of a combination of one or more networks selected from the 
group consisting of: a community access television (CATV) network, an 
asynchronous transfer mode (ATM) network, the Internet, a Public Swiched 
Telephone Network (PSTN), an Integrated Services Digital Network (ISDN), a 
local area network (LAN), or a wide area network (WAN). 

11. The telemedicine system of claim 1, wherein the first control unit 
receives video and voice data from videoconferencing equipment in communication 
with the control unit and delivers the video and voice data to the first 
communication device, the communication device encapsulating the video and voice 
data in packets in accordance with the preselected communications protocol and 
outputting the packets onto the network, wherein the second communication device 
receives the packets encapsulating the video and voice data and de-encapsulates the 
packets to reconstruct the video and voice data, the second communication device 
providing the video and voice data to the second control unit. 
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12. The teiemedicine system of claim 3, wherein the communications 
protocol is TCP/IP. 

13. The teiemedicine system of claim 4, wherein the communications 
protocol is TCP/IP. 

14. The teiemedicine system of claim 5, wherein the communications 
protocol is TCP/IP. 

15. The teiemedicine system of claim 6, wherein the communications 
protocol is TCP/IP. 

16. The teiemedicine system of claim 7, wherein the communications 
protocol is TCP/IP. 

17. The teiemedicine system of claim 8, wherein the communications 
protocol is TCP/IP. 

18. The teiemedicine system of claim 9, wherein the communications 
protocol is TCP/IP. 

19. The teiemedicine system of claim 10, wherein the communications 
protocol is TCP/IP. 

20. A method of acquiring and transporting data in a teiemedicine 
system, the method comprising the steps of: 

obtaining measurement data from at least one medical device located at a 
patient monitoring station, the measurement data representing a measurement of a 
physical condition of a patient, the measurement data being represented by one or 
more bits; 
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encapsulating the data in packets in accordance with a preselected 
communications protocol, each packet comprising a designation of a central 
monitoring station to which the packet is being sent; 

outputting the packets onto a network; 

receiving the packets at the central monitoring station designated by the 
designation comprised in the packets; 

de-encapsulating the packets to reconstruct the data representing the physical 
condition of the patient; and 

providing the reconstructed measurement data representing the physical 
condition to a control unit located at the central monitoring station. 

21 The method of claim 20, further comprising the steps of: 
obtaining video and voice data from videoconferencing equipment located at 
• a patient monitoring station; 

encapsulating the video and voice data in packets in accordance with the 
preselected communications protocol, each packet comprising a designation of the 
central monitoring station; 

outputting the packets onto the network; 

receiving the packets at the central monitoring station; 

de-encapsulating the packets to reconstruct the video and voice data; and 

providing the reconstructed video and voice data to the control unit located 
at the central monitoring station. 

22. The method of claim 20, wherein the packets output onto the network 
comprise a medical record and wherein the medical record comprises an indication 
of the patient's identity and of the type of measurement data comprised in the 

medical record. 
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23. The method of claim 21, wherein the packets comprising the 
measurement data output onto the network comprise a medical record and wherein 
the medical record comprises an indication of the patient's identity and of the type 
of measurement data comprised in the medical record. 

24. The method of claim 23, wherein the medical record further 
comprises an indication of the type of medical device from which the measurement 
data was obtained and an indication of a network address of the patient monitoring 
station. 



25. A method of acquiring and transporting data in a telemedicine 
system, the method comprising the steps of: 

generating medical device command data and application-level data in a 
control unit located at a central monitoring station, the data being represented by 
one or more bits; 

encapsulating the data in packets in accordance with a preselected 
communications protocol, each packet comprising a designation of a patient 
monitoring station to which the packet is being sent; 

outputting the packets onto a network; 

receiving the packets at the patient monitoring station designated by the 

designation comprised in the packets; 

de-encapsulating the packets to reconstruct the data; and 

providing the reconstructed data to a control unit located at the patient 

monitoring station. 

26. The method of claim 25, further comprising the steps of: 
obtaining video and voice data from videoconferencing equipment located at 

the central monitoring station; 

encapsulating the video and voice data in packets in accordance with the 
preselected communications protocol, each packet comprising the designation of the 
patient monitoring station; 
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outputting the packets onto the network; 
receiving the packets at the patient monitoring station; 
de-encapsulating the packets to reconstruct the video and voice data; and 
providing the reconstructed video and voice data to the control unit located 
at the patient monitoring station. 

27. A data signal for use in a telemedicine system, the data signal 
relating to a measurement obtained from medical equipment located at a patient 
monitoring station, the measurement corresponding to a physical condition of a 
patient, wherein the data signal is provided to a communication device which 
generates packets of data to be sent over a network, the data signal provided to the 
communication device comprising: 

a plurality of bits representing the measurement; 
a plurality of bits representing the patient's identity; and 
a plurality of bits representing the type of measurement obtained from the 
medical equipment. 

28. The data signal of claim 27 further comprising: 

a plurality of bits representing the date and time at which the measurement 
was obtained; 

a plurality of bits representing the type of medical equipment used to obtain 
the measurement; and 

a plurality of bits representing the location of the medical equipment on the 
network. 
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APPARATUS FOR MONITORING AND/OR 
CONTROLLING A MEDICAL DEVICE 

BACKGROUND OF THE INVENTION 

The present invention is directed to an apparatus for 
monitoring and/or controlling a medical device, such as an 
infusion pump, from a remote location. 

An infusion pump is used to automatically administer 
liquid medicant to a patient. The liquid medicant is supplied 
from a source of medicant and pumped into the patient via 
a catheter or other injection device. The manner in which the 
liquid is infused is controlled by the infusion pump, which 
may have various modes of infusion, such as a continuous 
mode in which the liquid medicant is continuously infused 
at a constant rate, or a ramp mode in which the rate of 
infusion gradually increases, then remains constant, and then 
gradually decreases. 

Typically, the monitoring of an infusion pump is per- 
formed by reviewing a visual display means incorporated in 
the infusion pump, and the control of the infusion pump is 
performed by activating an input device, such as a keypad, 
incorporated with the infusion pump. Consequently, the 
monitoring and/or control of an infusion pump is performed 
at the same location at which the infusion pump is disposed. 

SUMMARY OF THE INVENTION 

The invention is generally directed to a medical apparatus 
having a programmable medical device disposed at a first 
room location and a remote monitor and/or controller dis- 
posed at a second room location. 

In one aspect, the invention is directed to a medical 
apparatus having a medical device for administering a 
medical treatment to a patient, the medical device being 
disposed at a first room location and including means for 
administering the medical treatment to the patient and 
memory means for storing data regarding the medical treat- 
ment administered to the patient. The medical apparatus also 
includes a remote monitor for monitoring the medical treat- 
ment administered to the patient, the remote monitor being 
disposed at a second room location remote from the first 
room location, and means for transferring the data from the 
medical device to the remote monitor while the medical 
device is administering the medical treatment to the patient. 

The data may be transmitted to the remote monitor in 
segmented, noncontinuous data portions, and the means for 
transferring the data to the remote monitor may include 
means for repeatedly transmitting portions of the data from 
the medical device to the remote monitor and means for 
generating an interrupt when one of the data portions has 
been transmitted to the remote monitor, the interrupt causing 
the transmitting means to transmit another of the data 
portions from the medical device to the remote monitor. 

In a second aspect, the invention is directed to a medical 
apparatus having a medical device for administering a 
medical treatment to a patient, the medical device being 
disposed at a first room location and including means for 
administering the medical treatment to the patient and 
memory means for storing data regarding the medical treat- 
ment administered to the patient. The medical device also 
includes a remote monitor for monitoring the medical treat- 
ment administered to the patient, the remote monitor being 
disposed at a second room location remote from the first 
room location, a communication link operatively coupled 
between the medical device and the remote monitor, means 
for transferring the data from the medical device to the 
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remote monitor via the communication link, and means for 
allowing voice communication between the medical device 
and the remote monitor via the communication link while 
the data is being transferred from the medical device to the 
5 remote monitor. 

In a third aspect, the invention is directed to an apparatus 
having remote means for communicating with one of a 
plurality of medical devices each of which is designed to 
administer a medical treatment to a patient, the one medical 
10 device being disposed at a first room location and the remote 
means being disposed at a second room location remote 
from the first room location. The remote means includes 
means for automatically determining the type of the one 
programmable medical device and means for receiving data 
relating to the medical treatment of the patient after the type 
of the one programmable medical device has been deter- 
mined. The apparatus also includes data communication 
means coupled to the remote means for transferring data 
between the remote means and the one programmable 
medical device. 

20 The one programmable medical device may have a visual 
display device and the means for automatically determining 
the type of the one programmable medical device may 
include means for transmitting a display request to the one 
programmable medical device to request that the one pro- 
25 grammable medical device transmit display data including a 
plurality of characters shown on the visual display device of 
the one programmable medical device, means for receiving 
the display data, and means for determining the type of the 
one programmable medical device based upon the display 
J0 data. 

The display data may include a number of characters and 
the determining means may include means for determining 
the type of the one programmable medical device based 
}5 upon the number of characters in the display data. The 
means for automatically determining the type of the one 
programmable medical device may also include means of a 
first type for automatically determining the type of the one 
programmable medical device and means of a second type 
^ for automatically determining the type of the one program- 
mable medical device. 

These and other features and advantages of the present 
invention will be apparent to those of ordinary skill in the art 
in view of the detailed description of the preferred 
5 embodiment, which is made with reference to the drawings, 
a brief description of which is provided below. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a block diagram of an apparatus for adminis- 
tering medical treatment to a patient and monitoring the 
0 condition of the patient; 

FIG. 2 is a block diagram of the electronic components of 
the remote monitor/controller shown schematically in FIG. 

FIG. 3 is a front view of one embodiment of the infusion 
pump shown schematically in FIG. 1; 

FIG. 4 is a block diagram of the electronic components of 
the infusion pump of FIG. 3; 

FIG. 5 is a flowchart of the overall operation of the 
60 infusion pump; 

FIG. 6 illustrates a number of data-recording steps per- 
formed during the operation of the infusion pump; 

FIG. 7 is a representation of a portion of the memory of 
the infusion pump; 
65 FIG. 8 is a flowchart of a store data routine which can be 
used to store data relating to the operation of the infusion 
pump and data relating to the condition of a patient; 
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HO. 9 is a flowchart of a routine which may be used lo interface 102a, a nonvolatile RAM 104, a real-time clock 

identify the type of infusion pump to which the remote 106 and the display 92, all of which are interconnected by 

monitor/controller is coupled; , communications bus 108. Tie display 92 haTa backUgh" 

FIG. 10 is a flowchart of a mode select routine of the HO which is selectively activated by an enable signal 
remote monitor/controller; 5 generated on a line 112 interconnecting the controller 100 

FIGS. 11A-11B illustrate portions of visual displays and bac kl>ght HO. Both the RAM 104 and the real-time 

generated by the remote monitor/controller; cloclt I® 6 m connected to a battery 114 which supplies 

FIG- 12 is a flowchart of a command pump routine that is P ower 10 ^° al V "> ^ ^sence of system power. The 

performed by the remote monitor/controller; controller 100 has a transmit buffer 116 and a receive buffer 

mr. n™,„K,- _c .' 10 H8 connected to the communications bus 108 

HG. 13 is a flowchart of a receive routine that is per- _ ■ „ „ 

formed by the infusion pump ne con,ro| ler 1W controls the medicanl infusion rate by 

FIG. 14 is a flowchart o'f a transmit routine that is SSffi^ ' ^ ^ l ° 

performed by the infusion pump; and S . ^ ,V pUmp m0, ° r 124 wluch 

P, r „■ , ... , / .. , , , e dnves a pwnP'ng mechanism 126, such as a rotary pump 

k \ , a " 1 " ustrat,on of a ^P*" 031 «"»« that 15 wheel (not shown) adapted to make contact with a portion of 

may be displayed by the remote monitor/controller. the liquid conduit 16 (FIG. 1) connected to the catheter 14. 

DETAILED DESCRIPTION OF A PREFERRED ^ con,roUer 100 receives periodic inputs from a shaft 

EMBODIMENT encoder (SE) sensor 130, which is disposed on the shaft of 

c, r , •„, , , , ,. , n ,he motor 124- The SE sensor 130 may be a two-phase 

FIG. 1 illustrates one embodiment of an apparatus 10 for 20 motion sensing encoder which provides two signal outputs 

adminis enng medical treatment to a patient. Referring to to the controller 100. Tne rotational speed of the motor 124 

FIG 1, the apparatus 10 includes a programmable medical and its direction of rotation are determined by the controller 

treatment means in the form of an mfusion pump 12, which 100 based upon the rate and phase relationship between the 

is connected to a liquid medicant injection device in the form two signal outputs 

of a catheter 14 via a liquid conduit schematically shown as 25 ThfiiF™^!™™^- n . 

1 j 1 lnc »t encoder 130 periodically transmits the signals to 

Th. m • . a ■ , ,be controller 100 v 'f » line 132. Each time the signals are 

whlvETJ, "T" 6 m0Dll0 f ° nl ">« transmitted, an interrupt is generated, and the controUer 100 

which is deposed at a room location remote from the room compares the actual position of the motor shaft with its 

local on at which the infusion pump 12 is located. The desired position, and transmits a new control signal such as 

room of the same budding in which the pump 12 is disposed, line 122 to ensure that the actual speed of the motor 124 

or m a different building than the one in which the pump 12 corresponds to the motor speed retired for the desired 

is deposed. The remote monitor/controller 20 is connected medicant infusion rate. The interrupts caused by the SE 

^^JT^'I' m0< ! e T " a u da ' a £ k 24 ' 35 ™*" 130 ™ 'o the highest priority so that they 

votl ir « £ rf V t£ ' eph0nC 26 W a " re res P° nded 10 inunedulcl,. before any other actions are 

voice link 28. The infusion pump 12 is connected to a taken by the controller 100 

conventional voice/data modem 30 via a data link 32, and n,- ™. hi, u c u t 

the modem 30 is connected to a telephone 34 via a voice link h T k 8 !!" m , °! other L feat J lres not described 

36. The two modems 22, 30 are interconnected to Wto* JS,-^ the f ^° WiDg patem 

tiona. voice and data communication via a communication 40 ^f^^^^^^ 9 ^ 

link 38, which could be a telephone line, for example. «j„L"„ if u ° 8A39 '' 184, ^ ,ed . Mar , 6 ' 1995 ' ent,tled 

FIG. 2 is a block diagram of the electronics of the remote n^St? mZ^JT^T^ f ' "V" 

moni,or^oUer20shownschematicallyi„FIG.l.Refer- ^^^'J^XTi^JS^^ 

ring to FIG. 2, the remote monitor controller 20 includes a 45 Mar . 6 , 1995> entitled !, Q ^ sion ^ whO^d^. 

microprocessor (MP) 60, a read-only memory (ROM) 62, a ating Modes"; U.S. Ser. No. 08/398.886, filed Mar 6 ml 

WM^mT^ W M '- a , Dd 30 ' Q P" t/ ° utpU ' eDliUed " Casse,te For ^ Infusion Pump; U.S. Ser No! 
Sss/da b^68 T?L™ ^ mterconnected by an 08/399,183, filed-Mar. 6, 1995, entitled "Infusion Pump 
S^m ™ L? ^TT^ V ,raDSnUl Wi,h D""-.**** Mechanism"; U.S. Ser. No. 08/398.887, 

buffe mS? « for r^TvW 8 H f FT ^ * 50 filed ^ 6 ' 1995 « e " ti,Ied " hfus ™ ^ ™ Historic. 

Duner (Kfc<_) 72 for receiving data bytes. The remote Data Recording " 

monitor/controller 20 has a keyboard 74 connected to the -n. . <■ L • 

I/O circuit 66 via a line 76, a display device 78 such as a operation of the infusion pump 12 is controlled by a 

CRT, connected to the I/O circuit 66 via a line 80. and an ZT'" TT^JS^j 1 'If E ™ M , 104 ^ ° XM 

input device, such as an electronic mouse 82, connected to « ^ ' hC T?*, ™ ° f thC ° VetM ^ 

the I/O circuit 66 via a line 84. The remote monitor/ * ^f^^" H ?" * 10 ^ S ' wten the 

controller 20 can also include one or more disk drives such Tf t.u ° D ' " StCp . 202 the pWnp 15 "" tializ e d and 

as a hard disk drive or a floppy disk drive ? 0 ,he pUmp °P erallon 15 performed. The pump 12 may 

FIG. 3 is a front view of one embodiment of the infusion ^^12 mTconl™^ 8 * Which ^ 

pump 12 shown schematically in FIG. 1. Referring to FIG fin hlk Z ? 7 ^ ' the infusion when it is turned 
3 .Ote pump 12 h- an input /evice in the form o7a ke^d 6 ° ^^^1^^^^ 0 ^ r ^ 

j.i . ,. p ' ,. 8 , messa ges me user. the case where the pump was temporarily turned off during 

A Mock diagram of the electronics of the infusion pump an infusion, the program branches to step 206, where the 

12 is shown in FIG. 4 Refernng to FIG. 4, the pump 12 65 user is asked, via a message displayed on the display 92 

mchides a controller 100^ an electrically programmable whether the previous infusion should'be r£Z£u££ 

read-only memory (EPROM) 102 having a built-in I/O aaswers yes (via the keypad 90), the program branches tea 
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ready-to-run step 210. If the previous infusion is not to be 
resumed, the program branches to step 212. 

The infusion pump 12 has a lockout mode in which the 
user may be prevented from programming the infusion 
parameters, such as the volume to be infused or the rate of 
infusion. For example, the pump 12 could be programmed 
by a medical assistant to deliver a particular infusion having 
a particular flow profile, flow rate and volume to be infused. 
After programming that infusion, the medical assistant could 
place the pump in lockout mode, which would prevent the 
patient from changing any of the infusion parameters. At 
step 212, if the pump 12 has been previously placed in 
lockout mode, the program branches directly to the ready- 
to-run step 210, bypassing all programming steps. 

At step 212, if the pump is not in lockout mode, the 
program branches to step 214, at which point the program 
prompts the user, via the display 92, to input whether the 
patient should be allowed to program the pump during the 
subsequent infusion. If the pump is not to be programmable, 
the program branches to step 216 where a lockout sequence 
is performed by requesting the user to input which infusion 
modes should be locked out. If the pump is to be program- 
mable by the patient, the program bypasses step 216. 

The infusion pump 12 has five basic modes of infusion: 1) 
a continuous mode in which the pump delivers a single 
volume at a single rate; 2) an auto-ramp mode in which the 
pump delivers liquid at a rate that gradually increases to a 
threshold rate, stays constant at the threshold rate, and then 
gradually decreases; 3) an intermittent mode in which the 
pump delivers discrete liquid volumes spaced over relatively 
long periods of time, such as a liquid volume every three 
hours; 4) a custom mode in which the pump can be pro- 
grammed to deliver a unique infusion rate during each of 25 
different time periods; and 5) a pain-controlled analgesic 
(PCA) mode during which the pump will periodically infuse 
boluses of analgesic in response to periodic requests by the 
patient. 

At step 218, the pump 12 generates on the display 92 the 
prompt "Continuous?" to the user. If the user desires to use 
the pump in its continuous mode, the user answers "yes" via 
the keypad 90, and the program branches to step 220 at 
which the continuous mode is programmed by the user by 
entering a number of infusion parameters, such as the 
desired infusion rate, the volume to be infused, etc. At step 
218, if the user does not want to use the continuous mode, 
the user answers "No," and the program branches to step 
222. Steps 222-236 are generally the same as steps 218 and 
220, except that the user may be prompted for different 
infusion parameters, depending on which of the five possible 
infusion modes is selected. 

After the completion of one of the steps 220, 224, 228, 
232, or 236, the program branches to the ready-to-run step 
210. When the user presses the "Run" key, the pump 12 
enters the run mode 260 and infuses the patient with a liquid 
medicant in accordance with the infusion mode selected at 
one of steps 218, 222, 226, 230, 234 and the infusion 
parameters entered at one of steps 220, 224, 228, 232, 236. 
The pump 12 remains in the run mode 260 until the "Hold" 
key is pressed, as determined at step 262. Upon the occur- 
rence of an alarm condition, an alarm is reported at step 264. 
At step 262, if the hold key is pressed, the infusion is stopped 
at step 266, and the pump 12 waits for the run key to be 
pressed at step 268 or the on/off switch to be turned off at 
step 270. 

Summarizing the operation described above, if the pump 
is to be utilized in lockout mode, a medical assistant turns 



the pump on, programs the desired infusion mode at one of 
steps 220, 224, 228, 232, 236, and then turns the pump off. 
The programmed infusion parameters will be retained in the 
memory 104. The medical assistant would then turn the 
5 pump back on, press the "No" key in response to the 
"Programmable?" prompt at step 214, enter the lockout 
information at step 216, and then turn the pump off again. 
When the patient subsequently turned on the pump to 
perform the infusion, the program would proceed from step 
10 212 directly to the ready-to-run step 210, which would 
prevent the patient from altering the infusion parameters. 

If the lockout mode was not utilized, the medical assistant 
or the patient could turn the pump on, program the desired 
infusion mode, and then press the "Run" key to start the 
infusion without ever turning the pump off. 

During programming and operation, the infusion pump 12 
automatically records in the non-volatile memory 104 all 
significant infusion data to generate a complete historical 
20 data record which can be later retrieved from the memory 
104 and used for various purposes, including clinical pur- 
poses to aid in determining how effective a particular 
infusion therapy was and treatment purposes to confirm that 
the prescribed infusion was actually delivered. 
15 FIG. 6 illustrates various steps at which infusion data is 
recorded that are performed during the overall pump opera- 
tion shown generally in FIG. 5. The infusion data recorded 
in the memory 104 is set forth in Table 1 below. A number 
of events which trigger the storage of data are listed in the 
(0 left-hand column of Table 1, and the infusion data that is 
recorded upon the occurrence of each event is listed in the 
right-hand column of Table 1. The time at which the infusion 
data is recorded, which is determined by the real-time clock 
106, is also stored along with the infusion data. 
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TABLE 1 



EVENT 



DATA RECORDED 



Power On 

Program 

Run 

Hold 

Restart 

Rate Changes 

Alarms 

Infusion Complete 

Malfunctions 

Resume 

Maintenance Date 
Patient ID 
Serial No. 
Language Change 
Lockout 
Pressure Select 
Bolus Request 
Titration 
Power Off 
Version No. 



Date and Time 

Infusion parameters. See Table 2. 
Tnfurion parameters. See Table 2. 
Total Vblume Infused 
Time of Restart 

Total Vblume Infused, Rate, Volume 

Total Vblume Infused, Alarm Type 

Total Vblume Infused 

Total Vblume Infused, Malfunction Type 

Infusion parameters. Sec Table 2. 

Date 

Patient ID Number 
Serial Number 
New Language 
Modes Locked Out 
New Pressure Setting 
Given/Not Given, Bolus Amount 
New Parameters 
Tune of Power Off 
Software Version Number 



Referring to Table 1 and FIG. 6, when the power to the 
infusion pump 12 is turned on, the date and time of the 
power turn-on is recorded. When the pump is completely 
programmed pursuant to one of steps 220, 224, 228, 232, 
236 (FIG. 5) as determined at step 302, the programmed 
infusion parameters are stored at step 304, along with the 
time of such storage. The particular parameters that are 
stored depend upon which infusion mode was programmed. 
Several examples of infusion parameters that are stored for 
each of a number of infusion modes are illustrated in Table 
2 set forth below. 
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TABLE 2 



INFUSION MODE INFUSION PARAMETERS 



Continuous 


Infusion Mode 




Infusion Rate 




Vblumc To Be Infused 




Delay Time 




Total Bag Volume 




KVO Rate 


Auto- Ramp 


Infusion Mode 




Infusion Rate 




Volume To Be Infused 




Delay Tune 




Total Bag Vblumc 




Duration of Up- Ramp 




Duration of Down- Ramp 




KVO Rate 


Intermittent 


Infusion Mode 




Total Infusion Time 




Number of Doses 




Dose Time 




Dose Volume 




KVO Rate 



When the pump enters the run mode 260 (FIG. 5) as 
determined at step 306, the time at which the run mode was 
begun, along with the parameters pursuant to which the 
infusion is performed, are stored at step 308. 

At step 310, if the hold key is pressed, then the time at 
which the hold key was pressed along with the total volume 
infused at the time the hold key was pressed are stored at 
step 312. The pump also stores any infusion rate changes, 
such as changes caused by switching from a continuous rate 
to a keep-vein-open (KVO) rate, or in the intermittent mode, 
changing from a KVO rate to a higher infusion rate, the 
presence of which are detected at step 314. The new rate and 
the time at which the new rate started are stored at step 316. 

At step 318, if any alarms are generated, the alarm type, 
the time at which the alarm occurred, and the total volume 
infused at the time of the alarm are recorded at step 320. If 
the infusion is completed as determined at step 322, the 
program branches to step 324 where the time at which the 
infusion was completed is stored along with the total volume 
infused. At step 326, if there is a malfunction, the malfunc- 
tion type, the time at which the malfunction occurred, and 
the total volume infused at the time of the malfunction are 
recorded at step 328. 

At step 330, if the infusion is resumed (when the pump is 
turned back on after having been turned off during an 
infusion), the time at which the infusion is resumed along 
with the infusion parameters are stored at step 332. Upon the 
completion of the programming of a lockout sequence as 
determined at step 334 (i.e. after step 216 of FIG. 5), the time 
at which the programming of the lockout was completed is 
stored along with the infusion modes that were locked out. 
At step 338, upon the detection of a bolus request, the time 
at which the bolus was requested is stored at step 340, along 
with an indication whether the bolus was actually given and 
the amount of the bolus. 

FIG. 7 illustrates the data organization of a portion of the 
RAM 104 in which infusion data (the data stored during the 
steps of FIG. 6) is stored. Referring to FIG. 7, the infusion 
data is stored in a number of memory locations 372. Data 
may be written to the memory locations 372 utilizing a 
pointer 376 which specifies the memory location at which 
data should be next stored. 

FIG. 8 is a flowchart of a routine 380 for storing data in 
the memory locations 372. Referring to FIG. 8, at step 382 
the pointer 376 is set to the address of the next memory 
location 372 in which data is to be stored. At step 384, if the 
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pointer 376 is at the last memory location in which data may 
be stored, the routine branches to step 386 where the pointer 
is set to the address of the first memory location in which 
data may be stored. As a consequence of steps 384, 386, the 
5 contents of the memory locations 372 are periodically 
overwritten with new data; however, the number of memory 
locations 372 is sufficiently large so that several months of 
data, for example, is stored before being overwritten. At 
steps 388 and 390 the data is stored in the memory location 
10 372 specified by the pointer 376 (the data includes a time 
stamp generated from the real-time clock 106 and event data 
specifying the particular infusion event). 

FIGS. 9, 10, and 12 are flowcharts of various routines that 
are performed by the remote monitor/controller 20. As 
15 described in more detail below, the remote monitor/ 
controller 20 may be used to monitor the operation of the 
infusion pump 12, to control the operation of the infusion 
pump 12, and/or to transfer infusion data and patient data 
from the infusion pump 12 so that such data can be reviewed 
20 by a health care professional at a location remote from the 
patient. 

The remote monitor/controller 20 is designed to interface 
with different types of infusion pumps. In order to determine 
which type of infusion pump the remote monitor/controller 

25 20 is operatively coupled, a pump identification routine 400 
performed after the communication link between the remote 
monitor/controller 20 and the infusion pump 12 is estab- 
lished. Referring to FIG. 9, at step 402 the remote monitor/ 
controller 20 transmits a pump identification (ID) request to 

30 the infusion pump 12 via the communication link 38. In 
response to the pump ID request, the pump 12 transmits a 
multi-character ID code back to the remote monitor/ 
controller 20. The ID code may include, for example, one or 
more characters identifying the pump model and/or one or 

35 more characters identifying the software version of the 
pump. At step 404, the remote monitor/controller 20 reads 
the characters sent from the pump 12 until all characters are 
received as determined at step 406 or until a predetermined 
time period, e.g. five seconds, elapses. The time period may 

40 be determined by a timer (not shown). The remote monitor/ 
controller 20 may determine that all characters have been 
received by, for example, identifying one or more termina- 
tion characters, such as a carriage-return character <CR> 
followed by a line-feed character <LF>, 

45 Step 408 determines whether a correct response was 
received from the pump 12, which may be determined 
checking the characters received from the pump 12 against 
a list of possible ID codes. If a correct response was 
received, the routine branches to step 410 where the pump 

50 type is determined, for example, by comparing the received 
pump ID code with at least one possible ID code which 
identifies a particular type of infusion pump, or by compar- 
ing the received pump ID code with a number of possible ID 
codes, each of which identifies a particular type of infusion 

55 pump. As used herein, the "type" of infusion pump may 
relate to the model of the pump or the software version of the 
pump. 

If a correct response was not received as determined by 
step 408, at step 412 the routine determines whether the 
60 predetermined time period measured by the timer has 
expired prior to receiving a termination character. If so, the 
routine branches to step 414 where an error message is 
generated due to the pump's failure to respond to the pump 
ID request. 

65 At step 412, if some type of response (not a correct 
response) was received before the timer expired, the routine 
branches to step 416. Steps 416-426 comprise a second way 
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of determining the type of infusion pump 12 connected to example of a different virtual keypad is shown in FIG. 11B 

the remote monitor/controller 20, which is based on the Various virtual keypad configurations may be stored in the 

number of characters in the display 92 of the pump 12. For memory of the remote monitor/controller 20, each virtual 

example, a first type of infusion pump may have a display keypad configuration having a pump type code associated 
capable of displaying 12 characters, whereas a second type 5 therewith. Since the remote monitor/controller 20 initially 

of infusion pump may have a display capable of displaying determined the type of pump to which it was attached (via 

32 characters. Steps 416-426 determine the type of infusion the routine of FIG. 9), it can retrieve from memory and 

pump based on the number of characters in the display. display the corresponding virtual keypad for that type of 

At step 416, the remote monitor/controller 20 transmits a pump, 
pump display request to the infusion pump 12 to request the 10 After the virtual keypad is displayed, the health care 
pump 12 to transmit the content of its display 92. At step professional may control the operation of the infusion pump 
418, the remote monitor/controller 20 reads the display 12 by selecting any of the virtual keys with the mouse 82 
characters transmitted from the pump 12. At step 420, if a Other ways of selecting the keys could be utilized, such as 
predetermined period of time has elapsed or if a terminating a touch -sensitive screen or a display screen activated by 
character is received, the routine branches to step 422. At is radiation sensors. The infusion pump 12 responds to corn- 
step 422, if the predetermined time period measured by the mands entered via its keypad 90 and to commands generated 
timer elapsed prior to the receipt of a terminating character, from the remote monitor/controller 20. At steps 456 and 458, 
the routine branches to step 424 where an appropriate error any commands entered by the health care professional are 
message is generated. At step 426, the type of pump is transmitted to the infusion pump 12, and at steps 460 and 
determined based on the number of display characters that 20 462, the display of the pump 12 is transferred to the remote 
were received. monitor/controller 20 and displayed on the display device 78 

The routine could also exit step 420 if a predetermined of the remote monitor/controller 20. At step 464, if the user 

number of characters are received. In that case, where the exits the command mode, the routine branches back to step 

remote monitor/controller 20 was designed to interface with 452. 

two different types of infusion pumps, one having a display 25 At step 465, if the health care professional selected the 

capability of 12 characters and another having a display monitor mode, the routine branches to step 466 where a 

capability of 32 characters, if the remote monitor/controller visual display of the pump display 92 is shown on the 

20 received more than 12 display characters at step 420, it display device 78. At step 467, the contents of the pump 

would immediately be able to determine that the pump type display 92 are transferred to the remote monitor/controller 

corresponded to a pump with a 32-character display capa- 30 20, and at step 468 those contents are displayed in the visual 

biht y- display generated at step 466. At step 469, if the user exits 

The remote monitor/controller 20 allows four basic func- the monitor mode, the routine branches back to step 452; 

tions to be performed, including controlling the infusion otherwise, the routine branches back to step 467 so that the 

pump 12, monitoring the operation of the pump 12, trans- contents of the pump display 92 are continuously shown on 

fernng infusion data from the pump 12 to the remote 35 the display device 78 at step 468 (the display 92 of the 

monitor/controller 20, and viewing the data. The user may infusion pump 12 changes in accordance with the pump 

perform one of those functions by selecting an operational operation so that the pump operation can be monitored by 

mode displayed on the display device 78 (FIG. 2) of the viewing the display 92). Step 467 may be accomplished for 

remote monitor/controller 20 via the mouse 82. These modes example, by transmitting a pump display request to' the 

include a command mode in which a health care profes- 40 pump 12 (via steps similar to steps 416-420 described 

sional at the remote monitor/controller 20 may transmit above). 

command signals to the infusion pump 12 to control its If the health care professional inputs a request to down- 
operation, a monitoring mode in which the infusion pump 12 load data from the pump 12 to the remote monitor/controller 
will continually transmit the contents of its visual display 92 20 as determined at step 470, the routine branches to step 
to the remote monitor/controller 20, a download data mode 45 472 where the data transfer is accomplished, as described 
in which infusion data is transferred from the pump 12 to the below in connection with FiGS. 13-14. If the user inputs a 
remote monitor/controller 20, and a view data mode in view data log request as determined at step 474, the routine 
which the infusion data may be viewed on the display 78 of branches to step 476 where data previously downloaded at 
the remote monitor/controller 20. step 472 can be viewed on the display device 78 of the 
FIG. 10 illustrates a flowchart 450 of the basic operation so remote monitor/controller 20. The user may exit the mode 
of the remote monitor/controller 20. Referring to FIG. 10, at select routine 450 via step 478. 

step 452, if the user selected the command mode described FIG. 12 illustrates one routine that could be used to 

above, the routine branches to step 454 where a display of implement the transmit command step 458 shown schemati- 

the keypad 90 of the infusion pump 12 is shown on the cally in FIG. 10. Referring to FIG. 12, the pump command 

display device 78. The display shown at step 454 comprises 55 is transmitted from the remote monitor/controller 20 at step 

a plurality of virtual entry keys having a spatial configura- 480, and then the infusion pump 12 transmits to the remote 

tion substantially the same as the entry keys of the keypad monitor/controller 20 an echo of the command so that the 

90 of the particular infusion pump type which is connected remote monitor/controller 20 knows that command was 

to the remote monitor/controller 20. An example of such a received properly by the pump 21. The characters making up 

visual display is shown in FIG. 11A. so the echo are received at steps 482^84, and if the echo is not 

It should be noted that the virtual keypad shown in FIG. correct, an error message is displayed to the health care 

11A is the same as the actual keypad 90 of the pump 12, professional. At step 490, the remote monitor/controller 20 

which is shown in FIG. 3 (except that the on/off key of the sends an acknowledgement of the echo to the pump 12 

pump 12 is replaced with a reset key in the virtual key The transfer of data from the infusion pump 12 to the 

display). Where a different type of pump having a different 65 remote monitor/controller 20 shown schematically in step 

keypad is attached to the remote monitor/controller 20, that 468 of FIG. 10 is accomplished via a receive interrupt 

particular keypad is displayed on the display device 78. An service routine 500 and a transmit interrupt service routine 
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550 that are performed by the infusion pump 12. Flowcharts 
of the routines 500, 550 are shown in FIGS. 13 and 14. 

The receive routine 500 shown in FIG. 13 is invoked upon 
the generation of a receive interrupt by the pump controller 
100. The receive interrupt indicates that a message has been 5 
received in the receive buffer 118 of the controller 100 from 
the remote monitor/controller 20. When a download data 
command is sent to the infusion pump 12 (as determined at 
step 466 of FIG. 10), a data dump flag is set to logic "1," 
indicating that a data transfer or dump from the pump 12 to 
the remote monitor/controller 20 is in progress. The data 10 
transfer is performed in a segmented fashion. Instead of 
sending all of the infusion data and patient data stored in the 
RAM 104 to the remote monitor/controller 20 in a single, 
continuous stream, the data is sent in segmented portions, 
each of which is separated in time from its adjacent portions 15 
by a period of time, e.g. 100 microseconds. 

Referring to FIG. 13, when the routine begins at step 502, 
a character or message will have been just received in the 
receive buffer 118. At step 502, if the data dump flag is 
active, meaning that a data transfer is already in progress, 20 
then the routine branches to step 504, where the data dump 
flag is set to logic "0," effectively terminating the data dump 
operation, and an error message is transmitted to the remote 
monitor/controller 20 at step 506. This is done to prevent the 
data dump operation from interfering with any commands 25 
that are transmitted from the remote monitor/controller 20 to 
the infusion pump 12. 

If the data dump flag was not active as determined at step 
502, the routine branches to step 508 where the message just 
received in the receive buffer 118 is checked to determine 30 
whether it is a data dump command. If it is not, then the 
routine branches to step 510 where the pump 12 responds to 
the command. 

If the message is a data dump command, the routine 
branches to step 512 where a transmit pointer 513 (see FIG. 35 
7) is set to the oldest data in the RAM 104 that has not yet 
been transmitted to the remote monitor/controller 20. At step 
514, the data dump flag is set to logic "1" since a new data 
transfer operation is beginning. At step 516, the data byte 
specified by the transmit pointer 513 is retrieved from the 40 
RAM 104, and at step 518 the position of the transmit 
pointer 513 is updated (e.g. incremented) to point to the 
address of the next data byte to be transmitted. At step 520, 
the data byte retrieved at step 516 is formatted in ASCII; at 
step 522 the transmit interrupt is enabled; and at step 524 the 45 
reformatted data byte is transmitted from the infusion pump 
transmit buffer 116 to the remote monitor/controller 20 over 
the data link 38. 

When the first data byte is sent out from the transmit 
buffer 116, a transmit interrupt is generated by the controller 50 
100 to indicate that the transmit buffer 116 is empty and that 
another data byte can be transmitted. Upon the generation of 
the transmit interrupt, the transmit routine 550 is performed. 
Referring to FIG. 14, at step 552 the status of the data dump 
flag is checked. If the flag is not active, meaning that a data 55 
dump operation is not in progress, the routine branches to 
step 554 where the routine responds to the other interrupt. If 
the data dump flag is active, then the routine branches to step 
556, where it determines whether all of the segmented 
portions of the infusion data have been transmitted. This 60 
may be accomplished, for example, by determining if the 
transmit pointer 513 and the pointer 376 (FIG. 7) are 
pointing to the same memory location. If all the requested 
data has been sent, the routine branches to step 558, where 
the transmit interrupt is disabled, and then to step 560 where 65 
the data dump flag is reset to logic "0," effectively ending the 
data transfer operation. 
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If not all the data has been transferred as determined at 
step 556, the routine branches to step 562 where the data 
byte specified by the transmit pointer 513 is retrieved from 
the RAM 104. At step 564 the position of the transmit 
pointer is updated to point to the address of the next data 
byte to be transmitted. At step 566, the data byte retrieved at 
step 562 is formatted in ASCII, and at step 568 the refor- 
matted data byte is transmitted from the infusion pump 
transmit buffer 116 to the remote monitor/controller 20 over 
the data link 38. 

The transmit interrupts generated by the controller 100 to 
transfer the segmented data portions to the remote monitor/ 
controller 20 are assigned a lower priority than the interrupts 
generated in response to input of the shaft encoder sensor 
130, which is necessary to provide the desired infusion rate. 
Consequently, the transfer of the infusion data and patient 
data does not interfere with the ability of the pump 12 to 
provide the desired infusion rate, and the data transfer can 
occur while the pump is infusing the patient with the 
medicant. 

FIG. 15 is an illustration of a graphical user menu that 
may be shown on the display device 78 of the remote 
monitor/controller 20. The health care professional may 
select particular data for transfer or viewing, via a number 
of different parameters such as beginning date, ending date, 
types of data, etc. The particular manner in which particular 
data may be selected for transfer or viewing is not consid- 
ered important to the invention. 

Modifications and alternative embodiments of the inven- 
tion will be apparent to those skilled in the art in view of the 
foregoing description. This description is to be construed as 
illustrative only, and is for the purpose of teaching those 
skilled in the art the best mode of carrying out the invention. 
The details of the structure and method may be varied 
substantially without departing from the spirit of the 
invention, and the exclusive use of all modifications which 
come within the scope of the appended claims is reserved. 

What is claimed is: 

1. A medical apparatus, comprising: 

an infusion pump for administering a liquid medicant to 
a patient, said infusion pump being disposed at a first 
room location and comprising: 
a liquid injection device adapted to be connected to the 
patient; 

a conduit connected to said liquid injection device; 

a pumping mechanism for pumping said liquid medi- 
cant through said conduit and into said patient via 
said liquid injection device and for generating a 
pump signal indicative of the pump speed and for 
generating a pump interrupt when said pump signal 
is generated; 

a controller for controlling said pumping mechanism; 
and 

memory means for storing data regarding said liquid 
medicant administered to said patient; 

a remote monitor for monitoring said liquid medicant 
administered to said patient, said remote monitor being 
disposed at a second room location remote from said 
first room location; and 

means for transferring said data from said infusion pump 
to said remote monitor effective for transferring said 
data real-time while said infusion pump is administer- 
ing said liquid medicant to said patient and for gener- 
ating a transfer interrupt when said data is to be 
transferred; 

wherein said controller responds to said interrupts in 
accordance with predetermined priorities and wherein 
said pump priority is assigned the highest priority. 
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2. An apparatus as defined in claim 1 wherein said means 
for transferring said data from said infusion pump to said 
remote monitor comprises means for transmitting said data 
in segmented, noncontinuous data portions. 

3. An apparatus as defined in claim 1 wherein said means 
for transferring said data from said infusion pump to said 
remote monitor comprises: 

means for repeatedly transmitting portions of said data 
from said infusion pump to said remote monitor; and 

means for generating an interrupt when one of said data 
portions has been transmitted to said remote monitor, 
said interrupt causing said transmitting means to trans- 
mit another of said data portions from said infusion 
pump to said remote monitor. 

4. An apparatus as defined in claim 1 wherein said means 
for transferring said data from said infusion pump to said 
remote monitor comprises: 

means for loading a portion of said data into a transmit 
buffer coupled to said remote monitor via a communi- 
cation link; 

means for generating an interrupt when said data portion 
has been transmitted from said transmit buffer to said 
remote monitor via said communication link, said 
interrupt causing said loading means to transmit 
another of said data portions from said infusion pump 
to said remote monitor. 

5. A medical apparatus, comprising: 
a medical device for administering a medical treatment to 

a patient, said medical device being disposed at a first 
room location and comprising: 

means for administering said medical treatment to said 
patient and for generating a signal indicative of the 
rate of administering of said medical treatment and 
for generating an administrating interrupt when said 
administrating signal is generated; 
memory means for storing data regarding said medical 

treatment administered to said patient; and 
a controller for controlling said administering means; 
a remote monitor for monitoring said medical treatment 
administered to said patient, said remote monitor being 40 
disposed at a second room location remote from said 
first room location; and 
means for transferring said data from said medical device 
to said remote monitor effective for transferring said 
data real-time while said medical device is administer- 
ing said medical treatment to said patient and for 
generating a transfer interrupt when said data is to be 
transferred; 

wherein said controller responds to said interrupts in 
accordance with predetermined priorities and wherein 
said administering priority is assigned the highest pri- 
ority. 

6. An apparatus as defined in claim 5 wherein said means 
for transferring said data from said medical device to said 
remote monitor comprises means for transmitting said data 
in segmented, noncontinuous data portions. 

7. An apparatus as defined in claim 5 wherein said means 
for transferring said data from said medical device to said 
remote monitor comprises: 

means for repeatedly transmitting portions of said data 
from said medical device to said remote monitor; and 

means for generating an interrupt when one of said data 
portions has been transmitted to said remote monitor, 
said interrupt causing said transmitting means to trans- 
mit another of said data portions from said medical 
device to said remote monitor. 
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8. An apparatus as defined in claim 5 wherein said means 
for transferring said data from said medical device to said 
remote monitor comprises: 

means for loading a portion of said data into a transmit 
buffer coupled to said remote monitor via a communi- 
cation link; 

means for generating an interrupt when said data portion 
has been transmitted from said transmit buffer to said 
remote monitor via said communication link, said 
interrupt causing said loading means to transmit 
another of said data portions from said medical device 
to said remote monitor. 

9. An apparatus as defined in claim 5 wherein said 
medical device comprises an infusion pump and wherein 
said means for administering said medical treatment to said 
patient comprises: 

a liquid injection device adapted to be connected to the 
patient; 

a conduit connected to said liquid injection device; and 
a pumping mechanism for pumping a liquid drug through 
said conduit and into said patient via said liquid injec- 
tion devices. 

10. A medical apparatus, comprising: 

a medical device for administering a medical treatment to 
a patient, said medical device being disposed at a first 
room location and comprising: 

means for administering said medical treatment to said 
patient and for generating a signal indicative of the 
rate of administering said medical treatment and for 
generating an administering interrupt when said 
administering signal is generated; 

memory means for storing data regarding said medical 
treatment administered to said patient; and 

a controller for controlling said administering means; 
a remote monitor for monitoring said medical treatment 

administered to said patient, said remote monitor being 

disposed at a second room location remote from said 

first room location; 
a communication link operatively coupled between said 

medical device and said remote monitor; 
means for transferring said data from said medical device 

to said remote monitor via said communication link; 

and 

means for allowing voice communication between said 
medical device and said remote monitor via said com- 
munication link effective for allowing said voice com- 
munication real-time while said data is being trans- 
ferred from said medical device to said remote monitor 
and for generating a voice interrupt when said voice 
communication is initiated; 

wherein said controller responds to said interrupts in 
accordance with predetermined priorities and wherein 
said administering priority is assigned the highest pri- 
ority. 

11. An apparatus as defined in claim 10 wherein said 
means for allowing voice communication comprises: 

a first voice/data modem operatively coupled to said 
medical device; and 

a second voice/data modem operatively coupled to said 
remote monitor, said first and second voice/data 
modems being coupled to said communication link. 

12. An apparatus as defined in claim 10 wherein said 
communication link comprises a telephone fine. 

13. An apparatus as defined in claim 10 wherein said 
medical device comprises a programmable infusion pump. 
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14. An apparatus as defined in claim 10 additionally 
comprising means for controlling said medical treatment 
being administered to the patient from said second room 
location. 

15. A medical apparatus, comprising: 
a medical device for administering a medical treatment to 

a patient, said medical device being disposed at a first 
room location and comprising: 
means for administering said medical treatment to said 
patient; 

an input device operatively coupled to said adminis- 
tering means for allowing a user to input control 
commands to control said administering means, said 
input device having a plurality of entry keys dis- 
posed in a spatial configuration; and 

memory means for storing data regarding said medical 
treatment administered to said patient; 

a remote monitor for monitoring and controlling said 
medical treatment administered to said patient, said 
remote monitor being disposed at a second room 
location remote from said first room location, said 
remote controller comprising: 
a display device; 

means operatively coupled to said display device for 
generating a visual display of a plurality of virtual 
entry keys, said virtual entry keys having a spatial 
configuration substantially the same as said entry 
keys of said input device of said programmable 
medical device; and 

means for allowing a user at said second room 
location to activate said virtual keys to allow the 
user to control the operation of said programmable 
medical device from said second room location; 
and 

means for transferring said data from said medical 
device to said remote monitor while said medical 
device is administering said medical treatment to 
said patient. 

16. An apparatus as defined in claim 15 wherein said 
means for transferring said data from said medical device to 
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said remote monitor comprises means for transmitting said 
data in segmented, noncontinuous data portions. 

17. An apparatus as defined in claim 15 wherein said 
means for transferring said data from said medical device to 
said remote monitor comprises: 

means for repeatedly transmitting portions of said data 
from said medical device to said remote monitor; and 
means for generating an interrupt when one of said data 
jo portions has been transmitted to said remote monitor, 
said interrupt causing said transmitting means to trans- 
mit another of said data portions from said medical 
device to said remote monitor. 

18. An apparatus as defined in claim 15 wherein said 
15 means for transferring said data from said medical device to 

said remote monitor comprises: 

means for loading a portion of said data into a transmit 
buffer coupled to said remote monitor via a communi- 
cation link; 

20 * 

means for generating an interrupt when said data portion 
has been transmitted from said transmit buffer to said 
remote monitor via said communication link, said 
interrupt causing said loading means to transmit 
25 another of said data portions from said medical device 
to said remote monitor 

19. An apparatus as defined in claim 15 wherein said 
medical device comprises an infusion pump and wherein 
said means for administering said medical treatment to said 

30 patient comprises: 

a liquid injection device adapted to be connected to the 
patient; 

a conduit connected to said liquid injection device; 
a pumping mechanism for pumping a liquid drug through 
said conduit and into said patient via said liquid injec- 
tion device; and 

a controller for controlling said pumping mechanism. 
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